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(54) Multiple stream traffic emulator 

(57) A multiple stream traffic emulator (1) that gen- 
erates multiple stream packet based traffic pursuant to a 
selected statistical model under control of a processor 
(105). A plurality of input data streams can be gener- 
ated internally by the processor (105) or by an external 
processing element (1 08-1 1 0). An interdeparture queue 

(101) is used to store data representative of a selected 
statistical traffic model, comprising both a pattern of 
data traffic and a traffic load. A departure scheduler 

(102) reads this stored data out of the list maintained by 
the interdeparture queue (101) to identify the temporal 
relationships of data outputs among the plurality of input 
data streams. The departure scheduler (102) identifies 
the desired time of departure of each data packet as 
well as the selected stream from which the data packet 
originates. The departure scheduler (102) drives a cell 
generator (103) that produces and releases the result- 
ant output data stream for transmission to the equip- 
ment under test (106). 
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Description 

Field of the Invention 

[0001 ] This invention relates to test equipment and, in 
particular, to a multiple stream traffic emulator which 
functions to generate digital traffic for equipment to be 
tested. The system, in one implementation, uses a list 
that contains data which represents any of a plurality of 
various traffic models, which list is used to control the 
generation of data packets for multiple streams of data 
and the multiplexing of these multiple streams of data 
into an output transmission. 

Background 

[0002] In the field of test equipment, it is a problem to 
efficiently generate an output data stream that emulates 
the diverse statistical patterns of real world data trans- 
missions. This is especially pertinent in the field of data 
communications for remotely located devices wherein 
the equipment must be operational under adverse con- 
ditions, and responsive to various patterns of input data 
traffic. In order to exhaustively test such equipment, 
diverse patterns of data traffic as well as varying traffic 
loads must be simulated to ensure that the equipment is 
operational under the conditions that exist in their 
installed environment. 

[0003] The present state of the industry is that a large 
segment of the equipment manufacturers do not believe 
that the emulation of various patterns of real world data 
transmissions is either practical or effective to test their 
equipment. This segment of the industry typically field 
tests their equipment in real-world situations to thereby 
ascertain whether the equipment is property function- 
ing. A significant limitation of this approach is that unu- 
sual patterns of traffic are typically not encountered 
during the test phase and the equipment is therefore not 
thoroughly tested. In addition, the user does not have 
any control over the loads presented to the equipment. 
Thus, this method of testing essentially defers the iden- 
tification of subtle problems to the customer detection of 
inoperability of the equipment. 
[0004] An alternative test approach is to analyze the 
equipment based upon a theoretical analysis of the 
design. This analytical approach uses standard models 
of traffic generated by standards or industry research 
bodies, such as Bellcore, to review the efficacy of the 
equipment design. The standard models of traffic can 
provide accurate traffic data, but the limitation of this 
approach is that the accuracy of the analysis is limited 
to the ability of the researcher to compute traffic loads 
for a small number of statistical patterns. In addition, the 
interaction among various loads and the use of unpre- 
dictable loads are typically not reviewed due to the over- 
whelming computational load presented by such an 
analysis. 

[0005] In summary, the problem with testing data com- 
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munication and data processing equipment in the field 
of data communications is that there is no test equip- 
ment available to generate traffic loads that can be var- 
ied by the user to test equipment under widely varying 
5 traffic conditions. This is especially pertinent in the case 
of equipment which is connected to a transmission 
medium that carries multiplexed data traffic. 

Summary of the Invention 

[0006] The above described problems are solved and 
a technical advance achieved by the multiple stream 
traffic emulator which functions to generate a plurality of 
streams of packet based data traffic pursuant to a user 

15 &-'!'jcted traffic model. This is accomplished in one 
implementation of the system by the use of an interde- 
parture queue which functions to store data representa- 
tive of at least one selected traffic model, comprising 
both a pattern of data traffic and a traffic load. A user 

so selects a traffic model for each of a plurality of input 
streams, and multiple different traffic models can be 
concurrently supported by the interdeparture queue. A 
departure scheduler requests the next interdeparture 
value from the interdeparture queue and adds this value 

25 to the last scheduled departure time for each of the plu- 
rality of input data streams to schedule the next depar- 
ture. The departure scheduler identifies the desired 
time of departure of each data packet as well as the 
selected stream from which the data packet originates. 

30 The departure scheduler drives a cell generator which 
produces the resultant output data stream for transmis- 
sion to the equipment under test. The cell generator 
produces a data packet for an identified output data 
stream at the appropriate instant of time identified by 

35 the departure scheduler. 

[0007] This apparatus can concurrently incorporate 
data which present a plurality of types of loads and 
which have traffic characteristics that follow different 
models into the generated streams of cells. In this man- 

40 ner, the interactions among the various data streams 
occasioned by the concurrent presence of varying loads 
and varying data traffic types can be determined. The 
user can create any desired traffic conditions that they 
desire. 

45 [0008] In addition, the system can be implemented in 
a number of alternative ways to generate both determin- 
istic and statistical data traff ic patterns. The interdepar- 
ture values can be generated via the use of the above- 
noted list or they can be calculated in real time by the 

so incorporation of a processing element into the traffic 
generator, to thereby make the packet generation a 
function of real-time variables that are detected by the 
processing element. Furthermore, the content of the 
generated data traffic can be dynamically varied so that 

55 this architecture can be used to produce fixed length 
packets or packets of varying length, with the contents 
of the packets being dynamically determined. Thus, this 
system concept has broad applicability and provides the 
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flexibility to implement a wide variety of test environ- 
ments. 

Brief Description of the Drawings 

5 

[0009] 

Figure 1 illustrates in block diagram form the overall 
architecture of the multiple stream traffic emulator 
and an application environment in which it oper- 10 
ates; 

Figure 2 illustrates additional details of the structure 

of the interdeparture queue; 

Figure 3 illustrates the mapping of a stream to an 

interdeparture value; - --. J 5 

Figure 4 illustrates additional details of the structure 

of the departure scheduler; 

Figure 5 illustrates the process of a departure array 

search attempt; and 

Figure 6 illustrates the process of a departure array so 
replacement. 

Detailed Description of the Preferred Embodiments 

[0010] Data transmission based upon cell or packet 25 
technology is well known. In this technology, the 
sequence of information to be transmitted is broken into 
discrete segments termed cells or packets, with cells 
typically being fixed length and packets being variable 
length. The cell information is termed the payload and it 30 
contains user information bits and is given a header 
which includes network information bits to aid in identi- 
fying, checking and routing the cell. The cells can then 
be transmitted across the network independently of 
other cells in the information sequence. A well known 35 
implementation of such a data transmission technology 
is termed the Asynchronous Transfer Mode (ATM) 
which employs a 53 byte cell, which includes a 5 byte 
header and a 48 byte payload. Therefore, for this 
description, the implementation details of the multiple w 
stream traffic emulator are described in terms of the 
ATM technology. 

Architecture Considerations 

45 

[0011] The multiple stream traffic emulator functions 
to generate packet data representative of a typical traffic 
pattern for a plurality of independent input streams. The 
generation of the traffic is controlled by an element that 
generates data indicative of a pattern of data traffic for so 
each of a plurality of input data streams. This element 
can either produce this traffic pattern data in real time or 
this traffic pattern data can be resident in memory. In the 
real time application, a processor, such as a digital sig- 
nal processor (DSP), can be used to generate the traffic 55 
pattern data. In the pregenerated data instance, the traf- 
fic pattern data is typically produced by an external 
processing element and stored in a memory, where 



either the user can select from among various types of 
traffic pattern data stored in the memory, or the traffic 
pattern data for use in a single traffic emulation instance 
is stored in the memory. 

[001 2] The data traffic that is generated for each input 
stream comprises a series of cells that are generated 
and output pursuant to a typical traffic model. The plu- 
rality of input streams are uniform in that no input 
stream receives preferential processing for incorpora- 
tion into the output stream. However, each input stream 
can carry data traffic that differs in its content, traffic 
load and traffic pattern from the other ones of the plural- 
ity of input streams. The class of data traffic that is gen- 
erated can be constant bit rate, variable bit rate, 
available bit rate (where the channel provides feedback 
regarding the present bit rate capacity of the channel), 
random data, or any type of data traffic desired by the 
user. The characteristics of each input stream can be 
defined by the user, independent of the characteristics 
of the other input channels. Furthermore, the data car- 
ried by each input stream can be defined on a fixed or 
dynamic basis. Thus, the multiple stream traffic emula- 
tor enables the user to create any test configuration that 
is desired. 

[0013] The multiple stream traffic emulator is dis- 
closed herein as a list-based system, wherein an inter- 
departure queue stores the data indicative of the output 
cell generation schedule for each of the input streams. 
The interdeparture queue data is indicative of the time 
interval between successive output cells for each of the 
output streams. The interdeparture data reflects a distri- 
bution of output cells that corresponds to a selected 
deterministic or statistical traffic pattern. The list-based 
implementation of the multiple stream traffic emulator 
provides a clear illustration of the capabilities of the mul- 
tiple stream traffic emulator system. 

System Architecture of the Multiple Stre am Traffic 
Emulator 

[0014] Figure 1 illustrates in block diagram form the 
multiple stream traffic emulator 1 which functions to 
generate multiple stream packet data traffic pursuant to 
selected traffic models, as well as an operating environ- 
ment in which it operates. A typical operating environ- 
ment comprises the equipment under test 1 06, such as 
a data terminal, connected via a data communication 
medium 107 to the multiple stream traffic emulator 1. 
The multiple stream traffic emulator 1 receives its inputs 
from any of a number of sources, which can be an exter- 
nal source, such as a terminal/processor 1 08, a data 
communication connection 109. a data storage medium 
110. or an internal source, such as processor 105. The 
multiple stream traffic emulator 1 receives the inputs, 
which comprise control data that defines the statistical 
traffic model for each of the input streams as well as 
other operational/control data, and generates a multi- 
plexed stream of output data packets which can be 
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applied directly to an equipment under test 106 or can 
be transmitted via the data communication medium 107 
to the equipment under test 1 06. 
[001 5] The multiple stream traffic emulator 1 concep- 
tually consists of two segments: data generation and 
traffic generation. The data generation segment pro- 
duces the actual data that is transmitted to the equip- 
ment under test 106. The traffic generation segment 
receives data transmit request messages from the inter- 
face hardware 104 that interconnects the multiple 
stream traffic emulator 1 to the equipment undertest 
106 and returns an indication to the data generation 
segment of whether there is data to be sent, which input 
data stream is to be sent, and "-mages contention 
when more than one stream is ■ .Unq to send a cell. 
The data generation segment translates this received 
information to the actual data to be sent. In the multiple 
stream traffic emulator 1 , the data generation segment 
comprises the cell generator 103 and the traffic genera- 
tor segment comprises the interdeparture queue 101, 
departure scheduler 102 and the processor 105. 
[001 6] The data generation is managed in the multiple 
stream traffic emulator 1 by the use of an interdeparture 
queue 101 which functions to store data representative 
of at least one selected traffic model, comprising both a 
pattern of data traffic and a traffic load. A traffic model is 
selected for each of a plurality of input streams, and 
multiple different traffic models can be concurrently sup- 
ported. A departure scheduler 102 reads this stored 
data out of the lists maintained by the interdeparture 
queue 101 to identify the temporal relationships of data 
outputs among the plurality of input data streams. The 
departure scheduler 102 identifies the desired time of 
departure of each data packet as well as the selected 
stream from which the data packet originates. The 
departure scheduler 102 drives a cell generator 103 
which produces the resultant output data stream for 
transmission to the equipment under test 106. The cell 
generator 1 03 produces standard data packets for each 
of the output data streams and releases the generated 
packets into these streams at a time designated by the 
departure scheduler 102. An equipment specific inter- 
face 1 04 may optionally be provided to interconnect the 
cell generator 103 to the equipment under test 106 or 
the data communication medium 107. The equipment 
specific interface 104 functions to provide the physical 
interconnection as well as the protocol conversion nec- 
essary to enable the cell generator output to be pre- 
sented to the equipment under test 106. 
[0017] The traffic models used in this apparatus can 
be standard statistical models of traffic generated by 
standards or industry research bodies, such as Bell- 
core, to review the efficacy of the equipment design, or 
can be any user defined model of data traffic. Included 
in this architecture is the ability to incorporate a 
processing element 105 in the multiple stream traffic 
emulator 1 to thereby provide real time data traffic gen- 
eration based upon feedback received from, for exam- 



pie, the data communication medium in the case of 
available bit rate data transmissions (where the channel 
provides feedback regarding the present bit rate capac- 
ity of the channel). 

5 

Interdeparture Queue 

[0018] The data that defines the characteristics of the 
output packets are stored in the interdeparture queue 
io 101, which is shown in additional detail in Figure 2. The 
entry of this data into the interdeparture queue 101 is 
accomplished by providing both data (DATA or D) and 
address (ADDR or A) bus extensions from the proces- 
sor 105 which is the source of data to the interdeparture 
is queue 101 to the interdeparture queue logic circuit 201 . 
The instance of a processor provided source of data is 
illustrated in the preferred embodiment disclosed 
herein, although the above-mentioned alternative 
sources of data are possible. 
20 [0019] The interdeparture queue 101 maintains a plu- 
rality (128. for example) of independent and identically 
featured input data streams, using the interdeparture 
queue memory 202 to store the queue data. Each of the 
plurality of input data streams has its bandwidth and dis- 
ss tribution controlled by a concatenated queue which con- 
tains the list of interdeparture data and interdeparture 
control words. In particular, the input data streams are 
defined in terms of the time interval between the trans- 
mission of successive output packets. This simplifies 
30 the stream management task, since the data stored in 
the interdeparture queue memory 202 comprises an 
interdeparture word which defines this interdeparture 
time interval for each of the plurality of input data 
streams. Thus, the temporal pattern of output data 
35 packet transmissions for a particular input data stream, 
as defined by the sequence of interdeparture words, 
represents the selected statistical traffic pattern for the 
selected input data stream. Each of the plurality of input 
data streams may be transmitted once or continuously 
40 as defined by the control word entries written into the 
interdeparture queue memory 202. 
[0020] As shown in Figure 3, the interdeparture queue 
101 maps each of the plurality (128) of input data 
streams to a corresponding queue pointer 401 which 
45 contains eight bits of queue segment address, which 
data is accessed on an input data stream basis. The 
queue pointer 401 contains the queue segment number 
for the corresponding input data stream. In response to 
an input data stream being designated as requiring an 
so output, the interdeparture queue logic 201 loads the 
contents of the queue pointer 401 into the read pointer 
402 for the interdeparture queue memory 202. The read 
pointer 402 is 17 bits long and points to any location in 
the 128K x 32 bit word space of the interdeparture 
55 queue memory 202. The read pointer 402 is then used 
by the interdeparture queue logic 201 to lookup the cor- 
responding interdeparture word that is stored in interde- 
parture queue memory 202 for this designated input 



7 



EP 0 895 375 A2 



data stream. The interdeparture word contains a 21 bit 
interdeparture value field which represents the number 
of cell slots (standard time intervals) desired between 
consecutively transmitted cells for this stream, 3 bits of 
control and 8 unused bits. The interdeparture word is 5 
used as shown in Figure 6, with the departure scheduler 
102 computing the departure time for the next output 
data packet for this designated input data stream. The 
control field is decoded in order to work out how to mod- 
ify the read pointer and whether to output the interde- J0 
parture data value or to disable the data stream. 

Departure Scheduler 

[0021 ] The departure scheduler 1 02 and its operation is 
are shown in additional detail in Figures 4, 5 and 6. The 
departure scheduler 102 contains an array of data 
pointers (departure array 601), each of which repre- 
sents data indicative of the next desired output data 
packet departure time for a corresponding one of the so 
plurality of input data streams, as defined by the interde- 
parture queue 101. The departure array 601 thus con- 
tains the same number of entries as input data streams, 
in the present example, 128 entries. 
[0022] The departure scheduler 102 receives 2S 
requests to generate traffic from the hardware interface 
104. The hardware interface 104 may include some 
cell/packet level processing in addition to providing an 
interface to the transmission medium 107 and/or the 
equipment under test 106. The hardware interface 104 so 
typically produces a traffic request strobe on one of the 
control leads that connect the hardware interface 104 
with the departure scheduler 102. The departure sched- 
uler 102 responds to the received traffic request strobe 
with a response control signal indicative of the receipt 35 
and acceptance of this request. The departure sched- 
uler 102, then automatically identifies the earliest 
scheduled departure for an output packet and returns 
data identifying both the input data stream designated 
by this identified scheduled departure as well as the 40 
departure time. This is accomplished, as shown in Fig- 
ure 6, by the search controller 303 of the departure 
scheduler 102 activating the comparators 304. In order 
to expedite the processing of the search for the next 
packet departure time, the comparator function is exe- 45 
cuted in parallel, by using eight comparator elements to 
implement comparator 304. The search controller 303 
compares the data stored in current time buffer 502 with 
the contents of the departure array 601 . The contents of 
the current time buffer 502 represent the output of a 50 
counter which is incremented every cell slot. Thus, the 
search controller 303 monitors the present time of day 
to identify when one of the entries written into the depar- 
ture array 601 indicate that an output data packet is to 
be created for that input data stream at the present time. 55 
The search controller 303 looks for the oldest departure 
array data entry which is less than (earlier in time) than 
the present time. When the search controller 303 



locates departures that are due, the search controller 
303 outputs, in order, the address of the departure array 
entry to oldest address buffer 501 located in result 
encoder 305. The address of the memory location cor- 
responds to the identification of the associated input 
data stream. Thus, the address output indicates the 
identity of the input data stream, whose statistical traffic 
distribution, as stored in interdeparture queue memory 
202, requires the output of a data packet. 
[0023] It is obvious that the independent nature of the 
plurality of input data streams can result in multiple 
scheduled output packet departures for any cell slot. In 
order to resolve any such contention, the departure 
scheduler 102 uses the result encoder 305 to multiplex 
the input data streams to ensure fair treatment of all 
input data streams. Thus, all pending departures for a 
selected time interval (present time indicative of a cell 
transmission slot) are processed, even if these depar- 
tures must be implemented in the next successive time 
interval(s), before any departures scheduled for the 
next: time interval are scheduled. Thus, a failed depar- 
ture of an identified output data packet preempts future 
scheduled departures. The downside of this process is 
that it distorts the distribution of the delayed input data 
streams in which the preemption occurs, although the 
degree of distortion is minimal. The errors in the statisti- 
cal model introduced by this preemption process is dis- 
tributed across all of the input data streams since there 
is no preferential treatment among the plurality of input 
data streams. This error distribution thereby minimizes 
the impact of the errors on the input data streams and 
represents a typical real-world random error condition. 
[0024] Once an output data packet is generated for a 
selected input data stream, the departure scheduler 
102 rewrites the memory address location of departure 
array 601 that was just read out with data indicative of 
the next scheduled departure for the associated input 
data stream. This scheduling data is generated as 
shown in Figure 6 by retrieving the next interdeparture 
word value for the selected input data stream from the 
interdeparture queue memory 202, using the associ- 
ated queue pointer 401. The retrieved interdeparture 
word is read and the interdeparture value contained 
therein is loaded into the adder 605. The other input of 
adder 605 is the output of the old departure time buffer 
602, which contains data indicative of the last computed 
desired time for outputting a data packet for the selected 
input data stream. Due to contention, as noted above, 
the actual transmission time of the output data packet 
for the selected input data stream may not correspond 
to the time data stored in thee old departure time buffer 
602, but the stored data is used in the present computa- 
tion of preserve the statistical traffic distribution defined 
for this input data stream. Adder 605 combines the data 
which identifies the last desired departure time for this 
identified input data stream with the retrieved interde- 
parture word to produce an indication of the next sched- 
uled departure time for an output data packet for this 



so 



5 



BNSOOCID: <EP 0895375A2J > 



9 



EP 0 895 375 A2 



10 



designated input data stream. This is accomplished by 
adding the 21 bit interdeparture word data received 
from the interdeparture queue memory 202 to this input 
data stream's last departure time to create a new depar- 
ture time value which is written into the departure array s 
601 in the memory location whose address corre- 
sponds to the selected input data stream identification, 
which data is output from oldest address buffer 604. 
[0025] Thus, the departure scheduler 102 listens to 
traffic requests received from the hardware interface w 
104 and determines whether an input data stream is 
pending. The departure scheduler 102 then arbitrates 
among multiple input data streams waiting to transmit 
output data packets. The departure scheduler 102 then 
- - generates the output data stream. 15 

Cell Generator 

[0026] The cell generator 1 03 functions to receive out- 
put packet indications from the departure scheduler 20 
102, and generate output packets which are output via 
a synchronous interface to the instrument specific hard- 
ware interface 104 which generates the required real- 
time data payload for the instrument under test 1 06. The 
cell generator 103 can be implemented by means of a 25 
memory which contains a predetermined number of 
previously created packets, each packet capable of 
being assigned once to a single input data stream. The 
packets in a particular input data stream are part of a 
linked list in that each packet includes a pointer which 30 
points to the next successive packet in the input data 
stream. The cells produced by the cell generator are 
encapsulated in a packet which is 1 7 long words of pre- 
determined format. The output cells can be static in that 
they are read from memory and are fixed in content, or 35 
they can be dynamic in that there is real-time generation 
of a unique data contents for each cell. 
[0027] The cells that are generated can be packetized 
cells which include a cell as well as associated house- 
keeping data. The cells can contain real time data in 40 
that a processing element contained in the multiple 
stream traffic emulator 1 produces cell data as a func- 
tion of conditions extant at the present time. For exam- 
ple, a handshake protocol can be used to test the 
integrity of the link between the multiple stream traffic 45 
emulator 1 and the equipment under test 106. The mul- 
tiple stream traffic emulator 1 can also generate a 
pseudo-random load and transmits this data in the cell. 
The equipment under test 106 also generates the same 
pseudo-random load and compares the received cell so 
content with the device generated data. Any disparity 
between the two sets of data can be used to identify 
problems in the transmission medium 107 that intercon- 
nects the equipment under test 106 and the multiple 
stream traffic emulator 1, or the equipment under test 55 
106 itself. 



Interface to Instrumen t Under Test 

[0028] The cell generator 103 produces packets rep- 
resentative of the cells generated in response to the 
interleaved input data streams. These packets must be 
propagated to the equipment under test 106 for the test 
to be effective. Therefore, the cell generator 103 must 
typically be connected to a hardware interface 104 
device to interconnect the multiple stream traffic emula- 
tor 1 with the load which it drives. For example, the mul- 
tiple stream traffic emulator 1 must be connected with 
the communication medium 107 that serves the equip- 
ment under test 106 to thereby transmit the packets 
generated by the cell generator 103 to the equipment 
under test 106 that are ; jrconnected by the network 
107. There are presently available interface elements 
that can perform the interconnection function. For 
example, there exists ATM convergence chips termed 
"sunny chips" which serve to receive a packet input and 
output the data stream on to a communication medium 
107 in the proper formal and with the proper protocol. 
Thus, in an ATM environment, the hardware interface 
104 comprises an ATM convergence chip. 

Conclusion 

[0029] The multiple stream traffic emulator functions 
to generate multiple stream packet based traffic pursu- 
ant to a selected traffic model. The resultant data is 
effective to test the response of the equipment under 
test to traffic of varying traffic characteristics as well as 
to test the interactions among numerous input data 
streams as a function of the traffic placed on the various 
input data streams. The user can define the test sce- 
nario with particularity and the environment so defined 
is emulated efficiently and precisely. 

Claims 

1 . A traffic emulator system (1 ) for generating an out- 
put data stream comprising a plurality of input data 
streams of packet data, each of said plurality of 
input data streams of packet data having prede- 
fined data traffic characteristics, that are multi- 
plexed together to form said output data stream 
(107), said system CHARACTERIZED BY: a traffic 
generator means (101) for generating traffic data 
indicative of a pattern of data traffic for each of a 
plurality of input data streams, and a data generator 
means (102, 103), responsive to said generated 
traffic data, for producing a data packet for each of 
said input data streams pursuant to said pattern of 
data traffic for said plurality of input data streams. 

2. A system of claim 1 wherein said traffic generator 
means (101) comprises: a storage means (201) for 
storing said traffic data, indicative of said pattern of 
data traffic for each of said plurality of input data 
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streams, in list-based form in a memory (202); and 
a pattern generator means (105) for receiving said 
traffic data . indicative of said pattern of data traffic 
for each of said plurality of input data streams, from 
a data source (110) external to said traffic emulator 
system (1). 

3. A system of claim 2 wherein said storage means 
(201) reads said traffic data, indicative of said pat- 
tern of data traffic for each of said plurality of input 
data streams, from said memory (202); and said 
data generator means (102, 103), is responsive to 
said read traffic data, for computing a time at which 
an output data packet is to be transmitted for each 
of said plurality of input data streams by way of a list 
generator means (102) for generating a temporally 
ordered list of output data packets for said plurality 
of input data streams, and an arbitrator means 
(303) for arbitrating among at least two of said tem- 
porally ordered output data packets whose time at 
which a data packet is to be transmitted in said out- 
put data stream are identical to output said at least 
two output data packets in sequence. 

4. A system of claim 1 wherein said traffic generator 
means (101) comprises: a processor means (101, 
105) for generating said traffic data, indicative of 
said pattern of data traffic for each of said plurality 
of input data streams, pursuant to real-time param- 
eters measured by said traffic emulator system. 

5. A system of claim 1 wherein said data generator 
means (102, 103) comprises: a cell generator 
means (103) for reading control data associated 
with said traffic data, indicative of said pattern of 
data traffic for each of said plurality of input data 
streams, to create an output data packet defined by 
said control data; and a transmitter means (1 07) for 
transmitting said output data packet to an equip- 
ment under test (106) to test said equipment. 

6. A method, operational in a traffic emulator system 
(1), for generating an output data stream (107) 
comprising a plurality of input data streams (101) of 
packet data, each of said plurality of input data 
streams (101) having predefined data traffic char- 
acteristics, that are multiplexed (102) together to 
form said output data stream (107), said method 
CHARACTERIZED BY: generating data indicative 
of a pattern of data traffic for each of said plurality of 
input data streams (101), and producing, in 
response to said generated data, a data packet for 
each of said plurality of input data streams(101) 
pursuant to said pattern of data traffic for said plu- 
rality of input data streams (101). 

7. A method of claim 6 wherein said step of generating 
comprises: storing data, indicative of said pattern of 



15 375 A2 1 2 

data traffic for each of said plurality of input data 
streams (101), in list-based form in a memory 
(202), and receiving said data, indicative of said 
pattern of data traffic for each of said plurality of 
5 input data streams (101), from a data source (108, 
109, 110) external to said traffic emulator system 
d). 

8. A method of claim 7 wherein said step of generating 
io further comprises: reading said data, indicative of 
said pattern of data traffic for each of said plurality 
of input data streams (101), from said memory 
(202), and computing, in response to said read 
data, a time at which an output data packet is to be 
15 transmitted (103) for each of said plurality of input 
data streams (101) by way of generating a tempo- 
rally ordered list of output data packets for said plu- 
rality of input data streams (101), and arbitrating 
among at least two of said temporally ordered out- 
20 put data packets whose time at which a data packet 
is to be transmitted in said output data stream (107) 
are identical to output said at least two output data 
packets in sequence. 

25 9. A method of claim 6 further comprising: generating 
said data, indicative of said pattern of data traffic for 
each of said plurality of input data streams (101), 
pursuant to real-time parameters measured by said 
traffic emulator system (1); 

10. A method of claim 6 wherein said step of producing 
comprises: reading control data associated with 
said data, indicative of said pattern of data traffic for 
each of said plurality of input data streams (101), to 
35 create an output data packet defined by said control 
data, and transmitting said output data stream 
(107) to an equipment under test (106) to test said 
equipment. 

40 



45 



55 



7 



EP 0 895 375 A2 



FIG. 1 




EP 0 895 375 A2 



FIG. 2 



ASYNCHRONOUS 
CPU INTERFACE 



^•—201 




202 

S 




A 


INTER- 


INTERDEPARTURE 
QUEUE 
LOGIC 


D 


DEPARTURE 
QUEUE 
RAM 





STREAM ^ UKL | "| INTERDEPARTURE 
INTERDEPARTURE QUEUE DEPARTURE SCHEDULER INTERFACE 



FIG. 3 



STREAM 

FIG. 4 

TO/FROM INTERDEPARTURE QUEUE 




301- 



INTERRUPT 



SEARCH 
CONTROLLER 



COMPARATOR 
0...7 



RESULT 
ENCODER 



TO/FROM CELL GENERATOR 



EP 0 895 375 A2 



60 1 DEPARTURE ARRAY 



FIG. 5 



CURRENTJTIMF 



on FULL REQUEST 




501 

on OLDEST FOUND ^ OLDEST_ADDRESS f 

A 



FIG. 6 




10 



(12) 



Europaisches Paterttamt 
^fljll European Patent Office 

" Office europeen des brevets EP 0 895 375 A3 

EUROPEAN PATENT APPLICATION 



(88) Date of publication A3: 

09.07.2003 Bulletin 2003/28 



(43) Date of publication A2: 

03.02.1999 Bulletin 1999/05 



(21) Application number: 98104193.2 

(22) - Date, of filing: 09.03.1998 



(51) mt CI7-. H04L 12726 



(84) Designated Contracting States: 


(72) Inventor: Beanland, Matthew G. 


AT BE CH DE DK ES Fl FR GB GR IE IT LI LU NIC 


Ringwood, Victoria, 3134 (AU) 


NL PT SE 




Designated Extension States: 


(74) Representative: Schoppe, Fritz, Dipl.-lng. 


AL LT LV MK RO SI 


Schoppe, Zimmermann, Stockeler & Zinkler 




Patentanwalte 


(30) Priority: 31.07.1997 US 904188 


Postfach 246 


82043 Pullach bei Miinchen (DE) 


(71 ) Applicant: Agilent Technologies, Inc. (a Delaware 




corporation) 




Palo Alto, CA 94303 (US) 





(54) Multiple stream traffic emulator 

(57) A multiple stream traffic emulator (1 ) that gen- 
erates multiple stream packet based traffic pursuant to 
a selected statistical model under control of a processor 
(1 05). A plurality of input data streams can be generated 
internally by the processor (105) or by an external 
processing element (1 08-1 1 0). An interdeparture q ueue 
(101) is used to store data representative of a selected 
statistical traffic model, comprising both a pattern of data 
traffic and a traffic load. A departure scheduler (102) 
reads this stored data out of the list maintained by the 
interdeparture queue (101) to identify the temporal re- 
lationships of data outputs among the plurality of input 
data streams. The departure scheduler (102) identifies 
the desired time of departu re of each data packet as well 
as the selected stream from which the data packet orig- 
inates. The departure scheduler (1 02) drives a cell gen- 
erator (103) that produces and releases the resultant 
output data stream for transmission to the equipment 
under test (106). 



CO 

in 

cr> 

CO 

o 
Q. 
LU 




EP 0 895 375 A3 



European Patent EUROPEAN SEARCH REPORT 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Citation ot document with 

of ratevarrtpaseagag 



KEISER 6 ET AL: "TEST TRAFFIC GENERATION 
EQUIPMENT AND ALGORITHMS FOR EVALUATING 
ATMNETWORKS" 

COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE 
PUBLISHERS BV, AMSTERDAM, NL, 
vol. 19, no. 12, 

1 October 1996 (1996-10-01), pages 
962-971, XP0Q0635579 

ISSN: 0140-3664 

* abstract * 

Section 2.1 Test cell generator 

* figure 2 * 

Section 2.2 Network Interface module 

* figure 3 * 

Section 2.3 Test cell receiver 

* page 967 - page 970 * 

EP 0 595 440 A (COMDISCO SYSTEMS INC) 
" May 1994 (1994-05-04) 
abstract * 

page 7. line 1 - page 8, line 6 * 

US 5 481 549 A (TOKUYAMA SABURO) 

2 January 1996 (1996-01-02) 

* abstract * 

* column 1, line 15 - column 2, line 25; 
figures 1,3-6 * 

US 5 615 135 A (HERSHEY PAUL C ET AL) 
25 March 1997 (1997-03-25) 

■ abstract * 
column 1, line 15 - column 3, line 32; 

figure 5 * 



The present seared report has been drawn up for a) 



THE HAGUE 



16 May 2003 



CATEGORY OFCTTEO DOCUMENTS 



H04L12/26 



H01L 
H04Q 



Mikkelsen, C 



E": eoitier poteU dooument, but pubfah»d on, or 



2 



BNSDOCIO <EP 0895375A3 



EP 0 895 375 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 98 10 4193 



This annex lists the patent family r 
The members are as contained in 
The European Patent Office is in ri 



ambers relating to the pateri documents cited in the above-mentioned European search report. 
ie European Patent Office EDP lite on 

way liable for these particulars whioh are merely given for the purpose of information. 

16-05-2003 



04-05-1994 US 
AT 
CA 
DE 
EP 
JP 
JP 



5440719 A 
181162 T 
2107141 Al 
69325233 Dl 
059544Q A2 
3090388 B2 
8163132 A 



08-08-1995 
15-06-1999 
28-04-1994 
15-07-1999 
04-05-1994 
18-09-2000 
21-06-1996 



US 5481549 


A 


G2-01-1996 


JP 6327118G A 


09-11-1988 


US 5615135 


A 


25-03-1997 


NONE 





»e Official Journal of the European Patent Office, No. 12/82 



